Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000013_owner-urn-ietf _Tue Oct 8 16:39:51 1996.msg

Internet Message Format | 1997-02-19 | 9KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA08528 for urn-ietf-out; Tue, 8 Oct 1996 16:39:51 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA08515 for <[e-mail]>; Tue, 8 Oct 1996 16:39:33 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA20125  (mail destined for [e-mail]); Tue, 8 Oct 96 16:39:21 -0400
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id OAA06559; Tue, 8 Oct 1996 14:39:13 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 08 Oct 1996 14:46:20 -0600
To: Larry Masinter <[e-mail]>
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] advantages of NAPTR over PURLs
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

I'm going to try to summarize the last batch of messages from
Larry, Patrik, Michael, and myself.

A key point of contention seems to be shown when Larry says (at 07:10 PM
10/7/96 PDT)

>The DNS entries for resolver.purl.org already give you all the
>indirection you need. Why add more?

I (and I assume Michael and Patrik) do not agree with the assertion that
this is all the indirection that is needed. Let me try to show why, and
Larry can let us know if the reasons are convincing or if he wants to try
and change our minds.

Larry is correct that a great level of indirection can be achieved
by changing the set of IP addresses that are returned when looking up
some domain name, such as "resolver.purl.org". But all this indirection
is simply changing the list of machines that are part of some business
agreement with one organization. PURLs do not provide the indirection
that is necessary to switch resolution from one organization to another.
Assume we start with purl.org doing our resolution, and now want to do it
ourselves. Maybe we want to go into competition with purl.org. Or maybe
we are affiliated with the US Government and they mandate that all resources
paid for by US tax dollars shall be resolved at gpo.gov.
There are a number of believable scenarios where we want resolution to
occur on machines that *cannot* be pointed to by the domain name purl.org.
(Or any other single domain name).

Several of Larry's other questions, such as

> I don't understand why www.purl.org must have a shorter lifetime than
> any NAPTR name. You just vow to not reassign the name.

are answered by the above. It is not just that www.purl.org might go away,
it is that we might want to move resolution of our identifiers off
of any machines that can be identified by www.purl.org and onto machines
identified by the domain name of a competitor to purl.org, while purl.org
still exists.

So, that is why we believe that changing IP addresses under a fixed
domain name is not sufficient *indirection* capabilities.

In responding to the same point, Patrik said that

> it does not give the information about priority and
> protocol that is needed.

and Larry asked for the justification for the need for
priority information. Let me take a stab at that as well.

Assume we have a set of N machines which are providing the
service for scheme.purl.com. There is no reason to assume that
all these machines are equally capable. Some will be very
capable hosts, others not so able. The priority field is used
to preferentially direct resolution requests towards the more
capable machines, while still allowing some requests to be
sent to the less powerful ones. NAPTRs themselves do not provide
this field, we rely on the SRV record for that.

There were some other questions about A records and bugs, Michael
has addressed those.


Other arguments, both technical and business, can be made against the
notion of having the IETF standardize a resolution procedure that says
"map <scheme>:<id> to http://<scheme>.purl.org/<id>". The technical
arguments are analogous to those that were raised against the original
version of the handle protocol. Business arguments show up when Larry
quotes me:

> > For PURLs, we not only have to know the identifier, we have to know
> > what resolver to contact. We end up with things like:
> >   http://purl.bowker.com/isbn/1-56604-355-7
> >   http://purl.agicoa.com/isan/9961231234567891
>
> oh no! Clearly you only want to use the resolver.purl.org name.

Saying that all resolution requests go to <scheme>.purl.org mandates that
all organizations like Bowker, AGICOA, ASCAP, BMI, etc. (who have the
databases of identifiers and resources for particular schemes) establish a
business relationship with OCLC (*and any unspecified party that OCLC allows
to take over purl.org at any point in the future, no matter what their
policies*). This is not an acceptable solution.

In a later message, (Tue, 8 Oct 1996 00:59:24 PDT)
Larry raises a good point about the NAPTR resolution procedure not
having version information, so how do we know about:
  1) N2L, N2C, ... meaning the same things across time
  2) how to handle protocol changes such as rcds going to rcds2

First, changes in rcds (or other protocols) can be handled by
naming those protocols as rcds, rcds2, rcds3, ... in the protocol
portion of the services field.

If the group is concerned about versioning of the NAPTR record contents
and semantics, we have a couple of choices. One is that we define a
new RR at some point in the future. The second choice is that we use the
"flags" field. Currently we are allowing the digits 0-9 in the flags
field to be used for local experimentation (although I have no idea
what those experiments might be). We could reserve 2-9 for versions of
the interpretation of the fields of the NAPTR record. (The actual
number, type, and order of the fields in a DNS RR cannot be changed
once established, new RRs have to be defined to replace them).

I am not convinced that adding a new resolution request (call it N2X for
argument) mandates a new "version" of the NAPTR record. The services
field can easily accomodate it, it has no backward incompatabilitites,
clients and servers are not required to support all resolution services.
Adding a new request will require that all protocols that want to
support it specify how the request and result will be mapped into their
protocol, but if necessary the protocols themselves can be versioned
as noted above.

Larry also raise a good point when he says that:

>if you force people to register "dunslink" and "rcds" as new
>URL schemes, we'll have a mechanism for dealing with those tokens in a
>standards-track way. As you've specified it, there's no change-control
>on what those tokens might mean: if there are two versions of
>rcds, should NAPTR records upgrade all their records when the resolver
>upgrades from rcds1 to rcds2? If there's a version skew between the
>client rcds and the server rcds such that the server rcds can't
>respond to the client's ancient rcds implementation, should the
>rejection influence the handling of priorities?

We do need some registry for the protocols to have a degree of
change control. I am not sure that URL schemes are the best way to do
it, because of difficulties some protocols (Z39.50 for example) have
had in the past with making all their capabilities show up in a URL.
However, it is a reasonable starting point for discussion.

More contentious will be the registry for the namespaces. This is
a place where we stand a good chance of repeating the TLD battle
that is making life unpleasant for some of our colleagues. My current
rules for what should be allowed to be registered as namespaces are:
  1) Is it a namespace established by a recognized international
     standards body?  (ISBN, ISSN, SICI, ISAN, ISWC, FPI, OID, and
     a few others fit here).
  2) Is it a namespace estabished by an industry standards body with
     broad particiation? (SMPTE, IEEE, EIA,... are examples of the
     groups I am thinking of).
  3) This one is harder - is it a namespace established by a
     commercial organization for the use of any organization following
     normal business practices?  (This is to allow namespaces such as
     DUNS (30 million identified organizations), some of the Barcode
     registries (each can accomodate a few 10s of thousands of companies),
     etc. It is intended to disallow vanity namespaces. This may be
     impossible.

Both registries should be mentioned in the framework draft. We need a
really good lawyer to look at the language. Anyone know of a likely
candidate who would do it pro-bono?

Enough for now,

Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"